Software programs sometimes need to be patched (e.g., to correct an error, to implement a new feature, or for security reasons) after they have been released and are in use. For example, in systems in which functions, portions of functions or other code segments have been compiled into binary code representations of these functions or code segments, the compiled code sometimes needs to be replaced with new code that is compatible with the old code and its data structures. A code patching operation sometimes includes the insertion of code (sometimes referred to as a redirection patch) that redirects execution from one sequence of instructions to another. Other code patching operations include the replacement or insertion of code in the patch location itself (e.g., overwriting or augmenting existing code). Some existing techniques for performing binary patching require that all running threads of an executing program are halted while such a code patching operation is performed, e.g., in order to ensure that they are not affected by the patching.
A typical workflow for generating binary patches for a target program may include the following steps: start with the original source code and the originally generated binary, apply a source code patch (e.g., source code containing a functional correction or a security fix) to the original source code for the target program and create a new binary for the patched program, compare the two binaries to identify the locations within the binary code that have changed, and generate a binary patch based on this comparison. With a typical code patching workflow, small changes in one portion of the source code can sometimes have unintended side effects that ripple through unrelated portions of the binary code, even if no functional changes are made in the other portions of the source code.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.